IN THE SPECIFICATION 

Please amend the Specification as follows: 

Please amend the following paragraph spanning page 12 lines 12-20 through page 13 lines 1 
and 2 as follows: 

Transaction processing is preferably managed through interaction 
between database server 116, authorization system 108, and a transaction 
capture [and routing server] module 112. As can be seen from Figure 4, 
database server 116 suitably communicates card/account status information 
to authorization system 108. Status information generally includes account 
balance updates, status changes or the like for the various card accounts. 
For example, new cards are preferably assigned a "hold" status in 
authorization system 108 until consumer 100 initializes and validates the card 
as described above, at which time the authorization system preferably 
changes the status from "hold" to "pass" (or similar terms). A "hold" status is 
also preferably assigned if an account balance decreases below a minimum 
amount, or if a card is lost or stolen or the like. Accounts/cards that are 
assigned a "hold" status are preferably rejected by authorization system 108 
in any subsequent requests for transaction approval. 

Please amend the following paragraph spanning page 13 lines 3-21 and page 14 lines 1 and 2 
as follows: 

Point of sale terminal 104 is any device that is capable of identifying and 
gathering data from any stored value product. For example, point of sale 
terminal 104 could be implemented as an actual terminal in a store, an 
Internet server, a telephone system, a card reader in a vending machine, an 
automatic teller machine, or any other device that is capable of accepting 
stored value information in financial transactions. Point of sale terminal 104 
suitably communicates with authorization system 108 to approve or reject 
transactions based upon information available to the authorization system 
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108 from database server 116. Alternatively, authorization system 108 
supplements information from database server 116 with information obtained 
from other external sources (not shown) such as external authorization 
systems, credit reporting bureaus, etc. Authorization preferably takes place in 
real time, but in some embodiments the authorization is accomplished using a 
polling or batch processing scheme. In a preferred embodiment, when a 
consumer 100 presents a stored value card or enters an account at a point of 
sale terminal 104, the terminal sends an authorization request for the 
transaction to authorization system 108. Additionally, for some transactions 
(such as those involving very small amounts of money) point of sale [system 
terminal 104 may not transmit an authorization request at all. Although 
authorization may take place over any communications medium, authorization 
preferably occurs over a data communications link such as a telephone link, a 
leased line, the Internet, a wide area network, or the like. 

Please amend the following paragraph from page 14 lines 3-10 as follows: 

If the transaction is authorized, the transaction is preferably completed at 
point of sale terminal 104. Point of sale terminal 104 generally requests 
information such as the transaction amount and the identity of the stored 
value product used to pay for the transaction and this information is then 
suitably transmitted to transaction [captive] capture module 112 for 
settlement. To facilitate batch processing of settlement requests, merchants 
generally store information for multiple transactions. Alternatively, settlement 
requests are suitably transmitted in real time or are suitably polled by 
transaction capture module 112. 

Please amend the following paragraph from page 14 lines 11-21 as follows: 
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With continued reference to Figure 4, transaction capture module 112 suitably 
captures financial transaction data from POS terminal 104 and routes this 
information to database server 116. During a purchase transaction involving 
a stored value product, funds are suitably transferred from an account 
associated with a stored value card into a merchant's account. Records for 
card and merchant accounts are generally accessible by database server 
116, and are preferably maintained within database 142 (not shown in Figure 
4). A balancing system 118 is preferably located between database server 
116 and transaction processing module 112 to verify transaction data. 
Balancing system 118 is any computer system that provides a check based 
upon data received from database server 116 and transaction processing 
module 112. 

Please amend the following paragraph from page 15 lines 1-22 as follows: 

As best shown in Figure 5, a single report generator 136 preferably 
generates reports (1 ) for [customers] client system 138 using stored value 
products, as described above; (2) for merchants 140 that accept stored value 
products as compensation for goods or services; or (3) for consumers 100 
that receive, for example, periodic statements of their accounts and 
transactions. Alternatively, multiple report generators 136 create various 
reports. As another alternative, database server 116 internally generates 
some or ail reports without the use of an external report generator 136. In 
some embodiments of the invention, reports are generated in real-time (i.e. as 
requested by the account manager, the consumer, the database server 116, 
or any another entity). Alternatively, reports are processed in varying 
embodiments in batches, at predetermined times, when polled by the report 
generator, or by any other timing arrangement. Report generator 1 36 
preferably retrieves relevant data from a database associated with database 
server 116. In other embodiments, database server 1 1 6 provides necessary 
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data to report generator 136 as part of a report generation request. 
Alternatively, database server 116 suitably sends a pointer (such as a 
memory address accessible via a shared bus, or a uniform resource locator 
(URL), or any other pointer) to information that is stored. After obtaining data 
for the report requested, report generator 136 formats the data and provides 
the data to the proper client system 138. Various report generating systems 
are known in the prior art, and any report formatting system may be used in 
accord with the present invention. 

Please amend the following paragraph from page 16 lines 1-15 as follows: 

Figure 6 shows an exemplary embodiment of a combined system for adding 
cards, handling transactions and processing reports. As can be readily 
ascertained from Figure 6, a preferred embodiment of a stored value 
transaction system includes a database server 116 supporting multiple stored 
value products, each product preferably being associated with a particular 
client 1 38. Database server 116 preferably receives input from client system 
138 and from a [financial capture]/transaction [routing] capture module 112, 
as well as optional online input from consumers or customer service 
representatives 134. Stored value cards and accounts are preferably 
registered with an authorization server 108 that is configured to approve or 
deny individual transactions at various point of sale terminals such as terminal 
104 in the drawing figures. Preferably, database server 116 communicates 
with a report generating system 136 that is configured to assemble data into 
reports for client systems 138, merchants 140 and/or consumers 100, thereby 
formatting and simplifying data output from database server 116. 

Please amend the following paragraph from page 23 lines 3-11 as follows: 
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Customer records are preferably maintained in a customer data subsystem 
172 that generally implements a single database record for each customer 
even though the customer may use multiple stored value products. Card 
data, account data, client data customer data and the like ail generally reside 
within [client demographics] customer information subsystem 172, which 
frequently communicates with objects from the products, funding, transaction 
processing and address subsystems described herein. Additionally, many 
user interface elements such as screens and access control are generally 
contained within the client demographics subsystem. 

Please amend the following paragraph spanning page 23 line 18 to page 24 line 6 as follows: 

Addresses (including, for example, customer billing addresses, merchant 
addresses and the like) are preferably maintained in address subsystem 160. 
Address subsystem 160 generally houses address information and provides 
an interface with all other subsystems needing address information, such as 
the [client] customer and merchant data subsystems 172 and 168, 
respectively. Address subsystem 160 suitably provides a single point for 
maintaining substantially all of the address information stored in database 
142, and preferably supports multiple addresses for each person (e.g. home, 
business and Internet addresses, among others). Other objects in address 
subsystem 160 preferably support temporary addresses, optionally with an 
associated "effective date" such that forwarding addresses, traveling 
addresses, and the like are supported. 

Please amend the following paragraph from page 25 lines 1 1-17 as follows: 

Financial control subsystem 164 generally includes objects that are 
configured to substantially protect the financial integrity of database system 
116. Generally, financial control system 164 receives data from [external 
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financial] transaction capture [system] module 112, as well as funding 
subsystem 158 to maintain accurate account balance information. Financial 
control system 164 optionally includes objects that implement an interface to 
disputes and adjustments subsystems (not shown). 

Please amend the following paragraph from page 27 line 19 to page 28 line 12 as follows: 

Referring now to Figure 9, stored value products 186 are created using 
various objects from repository [114] 144. Generally speaking, users create 
new products in accordance with a particular business unit 188 by selecting 
suitable objects from repository [114] 144 that correspond to those attributes 
and functionalities desired in the new product 186. For example, a user may 
select, among others, an object for creating a card, various objects for storing 
value in an account associated with the card (or on the card itself), an object 
to manage financial transactions, and an object to generate reports for 
consumers. When these objects are selected, database server suitably 
assembles a product structure that references the various objects requested. 
In a preferred embodiment, product structures are tables of pointers to the 
various objects in repository [114] 144, but any suitable method of organizing 
the various objects (such as in a data structure or in a database record) could 
be used. When the product executes, database server 116 retrieves the 
particular objects requested. Because this method of constructing products 
substantially reuses objects of pre-written code, design and implementation 
times are significantly reduced. 

IN THE CLAIMS 

Please amend the claims as follows: 
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